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Introduction 


Systems  are  becoming  extremely  software-reliant 


Need  to  verify  and  validate  requirements 

•  Requirements  errors  propagate  through  design 

•  Need  to  verify/validate  requirements 


Major  integration  and  coding  issues  _ operation,,  so^h 

•  Incur  massive  re-engineering  rework  1 

•  Could  be  removed  by  early  analysis 

1,700 

135 _  236  B 

F-16A  Block  1  F-16D  Block  60  F-22  Raptor 

(1974)  (1984)  (1997) 


!  24,000 


F-35  Lightning  II  F-35  Lightning  II 
(2006)  (2012) 
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Architecture  Analysis  and  Design  Language 


Model-Based  Engineering  with  AADL 

•  Architecture  Language  Description  standardized  by  SAE 

•  Description  of  Systems  and  Software  Concerns 

•  Precise  &  unambiguous  semantics 

•  Textual  and  Graphical  Representation 


Support  for  Model  Analysis 

•  Verify  system  requirements  (i.e.  latency,  safety) 

•  Check  model  integration  before  producing  the  implementation 
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AADL  Model-Based  Technology  Overview 


Safety 
&  Reliabilit 

MTBF 
FMEA 

Hazard 
analysis 


Single  Source  Annotated  Architecture  Model 
with  Well-defined  Semantics 


Data 

Quality 

Data  precision/ 
accuracy 

Temporal 

correctness 

Confidence 


Architecture  Mode 


>. 


Auto-generated 
analytical  models 


Real-time 

Performance 

Execution  time/ 
Deadline 

Deadlock/starvation 


Security 

Intrusion 

Integrity 

Confidentiality 


Resource 

Consumption 

Bandwidth 
CPU  time 
Power 

consumption 


Latency 
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Understanding  Actual  Software  Issues 


High  Fault  Leakage  Drives  Major  Increase  in  Rework  Cost 


Aircraft  industry  has  reached  limits  of  affordability 
due  to  exponential  growth  in  SW  size  and  complexity. 


Requirements 

Engineering 


70%  Requirements  & 
system  interaction  errors 


System 

Design 


80%  late  error 
discovery  at  high 
rework  cost 


Acceptance 

Test 


\  (^70%,  3.5%  lx) 


10%,  50.5%  20x 


Software 
Architecture 
Design 


System 

Test 

Major  cost  savings  through  rework  avoidance 
by  early  discovery  and  correction 

A  SI  Ok  architecture  phase  correction  saves  $3M 


Integration 
Test 


Component  \  1 

Software  V  ' 

Design 

Rework  and  certification  is  70%  of  SW 
cost,  and  SW  is  70%  of  system  cost. 

Sources: 

NIST  Planning  report  02-3,  The  Economic  Impacts  oflnadequate 
Infostructure  for  Software  Testing.  May  2002. 

D  Galin,  Software  Quality  Assurance:  From  Theory  to 
Implementation,  Pearsoa'Addison-Wesley(2004) 

B.W.  Boehm,  Software  Engineering  Economics,  Prentice  Hall  (1981) 


20%,  16% 
5x  W 


Devi 


Unit 

Test 


Where  faults  are  introduced 
Where  faults  are  found 
The  estimated  nominal  cost  for  fault  removal 


Costly  certification  process  leads  to  high 
percentage  of  operational  work  around. 
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Use  of  AADL  in  Development  Process 


Software  and  Component  Design 

Define  components  requirements  &  interfaces 
Early  verification  validation  of  components  integration 

Code  Development 

Auto-Generate  Code  (AADL,  Simulink,  SCADE) 

Avoid  traditional  coding  errors 

Ensure  correct  translation  of  requirements 

Unit  &  Integration  Test 

Automatic  generation  of  tests  from  models 
Reduce  tests  as  system  was  validated  earlier 
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Security  Specifications 


Leverage  AADL  properties  for  security  level  specification 

Define  security-specific  values 

Associate  them  with  components  and  interfaces 


Direct  mapping  to  MILS  Security  Level  concepts 

MILS  subjects  to  AADL  runtime  components 
MILS  objects  to  AADL  interfaces 
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Partitioning  Policy  (as  in  arinc653  or  mils) 


Partitions  content  and  attributes 

Use  the  regular  process  component 
Include  partition  resources  (tasks,  data,  etc.) 

Time  and  Space  Isolation 

Time:  Partition  execution  slots 

Space:  Association  of  partitions  to  memory  segments 


PI 


Partition  1 
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Modeling  a  MILS  architecture  -  example 
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Safety  Policy  with  the  Error-Model  Annex  V2 


Standardized  AADL  annex  dedicated  for  safety  specification 

■  i  g  l  ai_i  a  A  rM  ConcurrencyError 

Integrated  with  AADL-core  - 

Extend/refine  existing  models 


Race  Condition 


MutExError 


Support  of  Error  Types  Ontology 


T 


7 


ReadWriteRace 


Write  WriteRace 


Deadlock 


Starvation 


Characterize  the  error  (i.e.  divide  by  zero,  late  value) 

Types  hierarchy  (i.e.  late  value  is  an  extension  of  a  timing  error) 


Error  Propagations  and  Behavior  Specification 

Errors  being  propagated  by  AADL  components 
Behavior  based  on  external  interfaces  or  sub-components 
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Error  Propagation 


Error  Type  Transformation 

* 


\i 

_ I _ 

Errors  Propagations  through  Interfaces 
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Error  Propagation  Example 


producer_prs 

consumer_producer::pr 


thread  producer 
features 

dataout  :  out  data  port  Character; 
annex  EMV2  {** 


ur^r i  1 

dataoi 

jt 

1  1 

prod  uc^to_co  nsu 


consumer_prs 

con  su  mer_prod  ucer:  :con  su  mer.  i 


fo 


aaiain 


H 


to 


use  types  errorlibrary; 

■  ICO _ htthjuinr _ trrnrl 


■Coi  1  Ar>riPQ 


r-  r\\i  a  r  • 


error  propagations 

dataout  :  out  propagation  {ValueError}; 

flows 

fO  :  error  source  dataout  {ValueError}; 

end  propagations; 


thread  consumer 
features 

datam  :  in  data  port  Character; 
annex  EMV2  {** 

use  types  errorlibrary; 

hohawinr  orrnrl  i 


component  error  behavior 
events 

ComputationError  :  error  event; 
transitions 

to  :  Operational  - [ComputationError] ->  Failed; 

propagations 

pO  :  Failed  -[]->  dataout{ValueError}; 

end  component; 


error  propagations 

datain  :  in  propagation  {ValueError}; 

flows 

fO  :  error  sink  datain  {ValueError}; 

end  propagations; 

component  error  behavior 
transitions 

to  :  Operational  - [datainfValueError}] ->  Failed; 

end  component; 
properties 


ynu'iuiiyuiiiui : 


properties 

EMV2: : severity  =>  ARP4761: ; Hazardous  applies  to  dataout. ValueError; 

EMV2: : OccurrenceDistnbution  =>  [  ProbabilityValue  =>  1.42e-5  ;  Distribution  =>  Poisson;] 
applies  to  dataout. ValueError; 

EMV2: : likelihood  =>  ARP4761: : Probable  applies  to  dataout. ValueError; 

EMV2: : hazards  => 

([  crossreference  =>  "TBD”; 
failure  => 
phases  =>  ("all"); 

description  =>  "Bad  Value  from  the  thread  producer"; 

comment  =>  "Must  check  the  software  that  the  value  is  not  faulty"; 

]) 

_ applies  to  dataout. ValueError; _ 
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Error  behavior 


States  machines 

Error-related  transitions 
Propagation  rules 
Use  of  error  types 


Composite  behavior 


Define  system  states  according  to  its  parts 


ex;  “I  am  failing  if  one  of  my  component  is  failing’’ 


— 

/  > 
Subsystem  1 

(Normal) 

V  '  J 

V _ 


- ^ 

— 

Subsystem  2 
(Normal) 

_ / 
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Error  behavior  example 


:pu. parti) ) 
:pu.part2) ) 

tl; 

t2; 


annex  EMV2  {** 

use  types  errorlibrary; 

use  behavior  errorlibrary: : FailAndRecover; 


applies  to  parti; 
applies  to  part2; 


composite  error  behavior 
states 

[parti . Failed] ->  Failed; 
[part2. Failed] ->  Failed; 
[cpu. Failed] ->  Failed; 

end  composite; 

**}; 

end  node.impl; 
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Security  Policy  Verification 


Component  integration  and  composition 

Partitions  share  the  same  level  with  their  tasks 
Partitions  contain  objects  at  the  same  level 

Runtime  issues 

Each  process  is  isolated  in  a  partition 

Partitions  has  at  least  one  execution  slot 

Memory  segments  contain  partitions  at  the  same  security  level 

Communication  Policies 

Communication  share  the  same  level 
A  shared  device  manages  objects  at  the  same  level 
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Specifying  Validation  Rules  with  RESOLUTE 


Specify  constraints  on  the  AADL  model 

Check  model  consistency  and  properties 
Validation  at  model  level,  avoid  propagation  of  errors 


List  of  rules  and  functions  to  check  the  model 

Select  elements  to  be  verified 

Filter  them  according  to  your  constraints 

Check  components  characteristics 

check_mils_partitions_connections  (s  :  system)  <= 

**  "Check  that  connected  partitions  in  11  s  "  share  the 

torall  (pi  :  process)  (p2  :  process)  (c 


Select  process,  connections  & 
virtual  processor  elements 


connection ) 


evel"  ** _ 

virtual  processor)  (vp2  :  virtual  processor) 


(connected  (pi,  c,  p2 ) )  and  ( processor bound  (pi,  vpl))  and  ( processor bound  (p2,  vp2)) 

=>  property  Ivp! 


I :  :  Security Leve L )  =  property  (vp2,  SEI :  : SecuntyLeve L ) 


Filter  connected  partitions 

Check  the  runtime  security 

with  their  associated  runtime 

level  is  equal 
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Generating  Assurance  Cases 

Generate  assurance-cases  using  RESOLUTE  and  AADL 

Show  constraints  dependencies 
Export  to  Certware 


• 

□- 

Problems  Q  Properties  1"  j  AADL  Property  Values 

&  Assurance  Case  23 

j' Search  yj  AGREE  Results  @  Console  ^Progress 

V 

v  */  Check  compliance  of  the  model  with  MILS  guidelines 


>  */  Check  that  component  'nodejmpljnstance  :  twoparts_mils::node.impl'  and  its  subcomponents  define  their  security  levels 
1/  Check  that  connected  partitions  in  'nodejmpljnstance  :  twoparts_mils::node.impl'  share  the  same  security  level 

V*  Check  that  memory  segments  in  system  s  'nodejmpljnstance  :  twoparts_mils::node.impl'  are  bound  to  partitions  with  the  same  security  level 
v  v!  Check  that  component  'nodejmpljnstance  :  twoparts_mils::node.impl'  has  subcomponents  at  the  same  level 
v  */  Check  that  component 'parti  :  twoparts_mils::pr_sender.impl'  has  subcomponents  at  the  same  level 
+/  Check  that  component  'prod  :  twoparts_mils: :  producer,  impl'  has  subcomponents  at  the  same  level 
v  ■</  Check  that  component  'part2  :  twoparts_mils::pr_receiver.impl'  has  subcomponents  at  the  same  level 
*f  Check  that  component  'recv  :  twoparts_mils::consumer.impl'  has  subcomponents  at  the  same  level 
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Safety  documentation  Generation  -  FHA 


Functional  Hazard  Assessment 

List  of  all  error  sources  of  the  system 


FHA  :  locale  -  Konsole  l^y  ^ 

SI  y  twoparts-mils_node_impl_lnstance _ FHA.csv  -  LibreOffice  Calc 

File  Edit  View  insert  Format  Tools  Data  Window  Help 

S-  -  -  /  i  ■  - 1  3  1  •  V  l  4-  S I  0 


[Nimbus  Sans  L  1 10  fl  M  'eL  S  =  = 

1  J  *)  «  £4  1  ffl  ’  £&  -  i  ’ 

\1 

-•  I  fw\  £  ^  (Component 

B 

Component 

[Error 

Hazard  Description 

2 

parti /prod 

ValueError  on  dataout 

Bad  Value  from  the  thread  producer 

3 

CPU 

AjKA/ 

HardwareErrqr  on  HardwareErrqr 

Hardware  Failure  of  the  CPU 

4 

cpu/partl 

AA/V  1 

SqftwareFailure  on  Sq.ftwareFailure 

Software  failure  from  the  platform  (OS  exception;  etc.) 

5 

cpu/part2 

AAW  1 

Software  [fail  u_re  on  SoftwareFailure 

Software  failure  from  the  platform  (OS  exception;  etc.) 

6 
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Safety  documentation  Generation  -  FTA 

Fault-Tree  Analysis 

Bottom-up  Approach 
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Safety  documentation  Generation  -  Fault  Impact 


Failure  Mode  and  Effect  Analysis 

Propagation  paths  of  failures 
Highlight  failure  containment 


C9 


twoparts-milsnodeimpllnstance _ Faultlmpact.csv  -  LibreOffice  Calc 


File  Edit  View  insert  Format  Tools  Data  Window  Help 

i  -  [Nimbus  Sans  L  [lO  hi)  ^  M  S'  H 


to 


N  »= 


vita  p 


d 2^  — 


Component  Initial  Failure  Mot  1st  Level  Effect 


1 


B 


Failure  Mode 

part2.recv  {ValueError}  [Masked] 
parti  {ServiceError} 


second  Level  Effect  Failure  Mode 


parti  . prod  (ValueError)  {ValueError}  dataout  ->  part2.recv:datain 

cpu. parti  [ServiceError)  [ServiceError)  bindings ->  parti :processor 

cpu.part2  internal  event  FailMItemOmission]  bindings  ->  part 2: processor  part2  [ItemOmission]  [Failure  Effect] 

cpu.part2  internal  event  SoftMLateServiceTermination]  bindings  ->  part2>part2  [LateServiceTemnination]  [Failure  Effect] 

cpu.part2  [ServiceError]  [ServiceError]  bindings  ->  part2: processor  part2  [ServiceError]  [Failure  Effect] 

_ r  r  VWWN/WVV  WVWSAAA/V  • 


[ValueError]  dataout  ->►  part2.recv  [ValueError]  [Masked] 
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Automatic  Code  Generation 


Automatically  produce  system  implementation 

Ensure  implementation  of  system  requirements 
Avoid  traditional  mistakes  of  manual  code  generation 

Low  overhead  (memory  footprint  and  additional  CPU  time) 

Less  than  10%  in  memory  and  computation  increase 
Benefits  outweigh  the  potential 

Support  for  different  runtime 

ARINC653/MILS  -  focus  on  safety/security  (DeOS,  POK) 
POSIX  (RTEMS,  Linux) 
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AADL  modeling  patterns  for  safety  and  security 


AADL  validation  tools  dedicated  to  security  and  safety 


Demonstration 
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Conclusion 


AADL  flexible  language  to  define  safety  and  security  concerns 

Early  verification,  reducing  tests  and  integration  costs 
Automatic  code  production,  avoiding  code  and  integration  mistakes 

Integration  with  existing  development  methods 

Safety  documentation  (i.e.  ARP4761) 

Coding  standards  (i.e.  ARINC653) 

Bridge  with  Validation  and  Assurance  Case  tools 

Check  model  consistency  and  composition 
Auto-Generate  assurance  cases  from  models 
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Links  &  Useful  Information 


AADL  website  -  http://www.aadl.info 
AADL  wiki  -  http://www.aadl.info/wiki 

ARINC653  AADL  annex  standard  -  http://standards.sae.Org/as5506/2/ 
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Contact 


Dr.  Julien  Delange 

RTSS  AP  Initiative 
Telephone:  +1  412-268-9652 
Email:  jdelange@sei.cmu.edu 


Web 

www.aadl.info 

www.sei.cmu.edu 

www.sei.cmu.edu/contact.cfm 


U.S.  Mail 

Software  Engineering  Institute 
Customer  Relations 
4500  Fifth  Avenue 
Pittsburgh,  PA  15213-2612 
USA 

Customer  Relations 

Email:  info@sei.cmu.edu 
Telephone:  +1  412-268-5800 

SEI  Phone:  +1  412-268-5800 

SEI  Fax:  +1  412-268-6257 
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